[grid] Forward file upload/download for Kubernetes, Docker and relay sessions - #17914

🔗 Related Issues

Fixes SeleniumHQ/docker-selenium#3206 (remote file upload fails on the Kubernetes Dynamic Grid).

💥 What does this PR do?

On the Kubernetes Dynamic Grid (node-kubernetes), LocalFileDetector-based remote file uploads fail with File not found. The uploaded file lands on the Node Pod, but sendKeys runs in a separate browser Job Pod that cannot see it.

The root cause is an asymmetry in LocalNode: uploadFile() (and downloadFile()) only forward the command to the downstream session when it is a DockerSession. Docker Dynamic Grid works because the command is forwarded into the browser container; Kubernetes was never forwarded, so the file was written to the Node's own filesystem instead of the browser Pod's.

This PR forwards file upload and download commands to the session whenever the browser runs in a separate environment from the Node:

• Docker container (already worked — behavior preserved)
• Kubernetes Job Pod (the reported bug)
• Relay target — an external endpoint (cloud provider, Appium device farm, another Selenium) that likewise does not share the relay Node's filesystem

Static Grid Nodes (browser in the same Pod/process as the Node) are unchanged and continue to be served from the Node's local filesystem.

🔧 Implementation Notes

The obvious fix — adding || slot.getSession() instanceof KubernetesSession next to the existing DockerSession check — was deliberately avoided. The kubernetes package pulls in the io.fabric8:kubernetes-client dependency, which is intentionally kept as an optional runtime extension (loaded via --ext; note fabric8-compile-only with neverlink = True and the kubernetes-embedded target). Making the core local package depend on kubernetes at compile time would drag fabric8 into core and break that extension model.

Instead this introduces a small capability method on the shared ActiveSession interface (which local, docker, kubernetes, and relay already depend on):

default boolean isRemoteFileSystem() {
  return false;
}

• DockerSession, KubernetesSession, and the relay session (RelaySessionFactory) override/report it as true.
• LocalNode.uploadFile() / downloadFile() forward the command when the session reports a remote filesystem.
• Plain sessions keep the default false and are handled locally.

This removes the Docker-specific coupling from LocalNode, and fixes downloadFile() too, which had the identical Docker-only asymmetry (managed downloads / se/files would also fail on Kubernetes — not mentioned in the issue, but broken the same way).

Note on relay: relay targets are heterogeneous, and some (e.g. Appium device farms) use their own file-upload mechanism rather than the Grid /se/file endpoint. Forwarding is the correct default for a browser that does not share the Node's filesystem; if a specific relay target does not implement /se/file, that is a target-side concern. Happy to gate relay forwarding behind a capability/flag instead if maintainers prefer.

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s): Claude Code
  • What was generated: The ActiveSession.isRemoteFileSystem() capability method, the DockerSession/KubernetesSession/relay overrides, the LocalNode upload/download changes, and the LocalNodeTest / RelaySessionFactoryTest regression tests.
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

The full build/tests could not be run in the authoring environment (the sandbox's egress policy blocks the Bazel binary download), so CI is the first place these targets run. The change is small and self-contained; the added tests exercise both the forwarded (remote-filesystem) and local (shared-filesystem) paths for upload and download, and assert that a relay session reports a remote filesystem.

🔄 Types of changes

• Bug fix (backwards compatible)